-
-
Notifications
You must be signed in to change notification settings - Fork 227
Fix deserialization of unions #319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix deserialization of unions #319
Conversation
Collapses the child elements into one, without class heirarchy, mixins, etc This is a replaying of 2670d11 (first implementation) and 9f5b95a (a bugfix) onto the new `main-v.0.7.0`, modified for the refactored upstream. This should bring `main-v.0.7.1` up to par with `main` for the features we implemented in our fork (dropping our `Unset` implementation for theirs)
Add support for generating setup.py and the initially generated one
@forest-benchling sure thing, I'll make sure to take a look at them before then. Can you rebase open PRs against main so it's easier to see what changed? Also since I've decided not to go forward with #297, if this really does depend on that is it possible to separate them? |
Yes, I will try. Sorry, this will take some time because so much has happened in the meantime that the merge conflicts are a mess 😬 |
NOTE: this has merge conflicts, because it's based off the
benchling
fork. I just wanted to get it up for review for visibility, I will change it to be based offtriaxtec
once you have bandwidth to review it.Depends on #297
Deserialization of unions in
from_dict
was not working properly, because it failed to account for cases where the union property isNone
orUnset
. This PR adds explicit checks forNone
orUnset
.In addition, the type of the value to deserialize was previously set to
Any
, which was masking type errors. In order to fix these type errors, I introduced a new concept ofcheck_type_for_construct
for each property, which allows the type to be checked before attempting deserialization.In the future, I think we should refine the
try/except
pattern; it's not good practice to rely on a catch-allexcept
when trying to deserialize each type within the union, because we don't know what exception was actually raised.